FIG. 1 schematically illustrates the logical structure of an optical transport network in accordance with ITU-T recommendation G.8080/Y.1304, entitled Architecture for the Automatically Switched Optical Network (ASON), the entire content of which is incorporated herein by reference. As may be seen in FIG. 1, the network 2 is logically divided into a transport plane 4, a control plane 6 and a management plane 8.
The Transport Plane 4 comprises a plurality of switches 10 interconnected by Physical Interfaces (PIs) 12, and is responsible for transporting user data via end-to-end connections provisioned through the network. The Transport Plane typically utilizes a Transport Plane Name Space (TPNS) which defines the set of identifiers, tags and addresses used in the Transport Plane, for example to identify each of its elements and the connections provisioned within it (including, for example, switches 10, PIs 12 and connections)
The Control Plane 6 comprises a respective Optical Connection Controller (OCC) 14 for each switch 10 of the transport plane 4, and is responsible for resource and connection management within the transport plane 4. Each OCC 14 is connected to its corresponding switch 10 of the transport plane 4 via a Connection Controller Interface (CCI) 16. Within the Control Plane 6, the OCCs 14 are interconnected via Network to Network Interfaces (NNIs) 18, and provide a set of network resource and connection management functions. These functions may, for example, include: network topology discovery (resource discovery); address assignment; path computation, connection set-up/tear-down; connection protection/restoration; traffic engineering; and wavelength assignment. Other management functions can be implemented by the control plane 6, as desired. The Control Plane 6 typically utilizes a Control Plane Name Space (CPNS) which defines the set of identifiers, tags and addresses used, in the Control Plane, to identify elements of both the Control Plane and the Transport Plane. Typically, the Control Plane 6 introduces resource management concepts and entities that do not exist in the Transport Plane 4, and the CPNS is therefore required to be more extensive than the TPNS, in order to facilitate its expanded functionality. The additional Control Plane concepts and entities include, for example, network domains, areas, calls, and traffic management functions such as protection switching and restoration. Each CCI 16 implements a “binding”, or mapping, between the CPNS and the TPNS, and thereby enables the respective OCC 14 to implement control plane functionality for its corresponding switch 10.
Typically a physical node of the network will incorporate both a Transport Plane switch 10 and its corresponding Control Plane OCC 14, although this is not essential. In some cases, a Transport Plane switch 10 and its corresponding Control Plane OCC 14 may be provided in separate physical machines. For example, the respective OCCs 14 of one or more switches 10 may be hosted on a server (not shown). Furthermore, in practical networks, some of the Transport Plane switches 10 may not have a corresponding Control Plane OCC 14. As may be appreciated, where a switch 10 does not have a corresponding Control Plane OCC 14, the switch is not control-plane enabled, and Control Plane functions cannot be used to control resources of that switch.
The Management Plane 8 is responsible for managing the Control Plane 6, and may also implement management functions in the Transport Plane 4, either directly or via the Control Plane 6. For example, in a typical network, the Management Plane 8 will directly control any switches 10 of the Transport Plane 4 that are not control-plane enabled. Responsibilities of the Management Plane 8 typically include Configuration Management of the Control Plane Resources, Routing Areas, Transport resource in Control Plane, and Policy. It may also provide Fault Management, Performance Management, Accounting and Security Management functions. The Management Plane 8 typically comprises a Network Management Entity 20 (such as, for example, a central management server) which is connected to an OCC 14 in the Control Plane 6 via a Network Management Interface for ASON Control Plane (NMI-A) 22 and to a switch 10 of the transport plane 4 via a Network Management Interface for the Transport Network (NMI-T) 24.
Client premised equipment (CE) 26, which may be a server or a router, for example, can send and receive packets that contain information for both the Transport Plane 4 and the Control Plane 6. For this purpose, the CE may be connected to a switch 10 of the Transport Plane 4 via a PI 12, and to its corresponding OCC 14 via a User Network Interface (UNI) 28.
IETF RFC 5852 describes a process for in-service migration of label switched paths (LSPs) from the Management Plane 8 to the Control Plane 6, which is referred to herein as an “MP-to-CP migration”. The entire content of RFC 5852 is incorporated herein by reference. The MP-to-CP migration process enables the Control Plane 6 to acquire “ownership” of existing connections in the Transport Plane 4 that were previously being managed by the Management Plane 8. In this context, the acquisition of ownership of a connection means that the acquiring plane (in this case, the Control Plane 6) assumes responsibility for managing the connection. In the case of the MP-to-CP migration, this means that the Control Plane 6 assumes responsibility for managing the connection, and provides the full range of Control Plane functions in respect of that connection. As part of the migration, the Management Plane 8 relinquishes control of the connection, and so will only provide Management Plane functions in respect of that connection via the Control Plane 6. The MP-to-CP migration provides a useful mechanism by which a legacy network (comprising only a Transport Plane 4 and the Management Plane 8) can be upgraded to include a Control Plane 6.
RFC 5852 also describes an in-service CP-to-MP migration process, which is the reverse of the above-noted MP-to-CP migration. Thus, the CP-to-MP migration enables the Management Plane 8 to acquire ownership of existing connections in the Transport Plane 4 that were previously being managed by the Control Plane 6. This provides a convenient mechanism by which Management Plane functions in respect of a connection can be restored, in the event of a failed MP-to-CP migration.
For the purposes of the present application, the term “in-service” shall be understood to mean that traffic flows through the involved connection in the Transport Plane 4 are not disrupted.
For the purposes of the present application, the terms “CP-to-MP migration” and “MP-to-CP migration” shall be understood to include the in-service requirement.
For the purposes of the present application, the terms “call”, “connection” and their cognates shall be interpreted as having the meanings as defined in relation to automatically switched optical networks (ASONs), pursuant to ITU-T recommendation G.8080/Y.1304.
Over the lifetime of a network, it may be necessary to perforin in-service network reconfigurations, such as: inserting/removing nodes in the network and into existing connections in particular; merging or splitting network domains or areas; extending or reducing the control plane's span of control of a connection (for example, changing the number of control-plane-enabled switches traversed by the connection); and changing from one Control Plane technology to another.
Different types of network reconfiguration may require respective different specific procedures. For example, FIG. 2 illustrates a known procedure for changing the path of an existing connection, for example to insert or remove a node from the connection, without significantly disrupting Transport Plane traffic flow through the connection. Referring to FIG. 2, in a first step (S2), an alternate end-to-end path through the network is computed for the connection, and an alternate connection set up along that path (at step S4). Once the alternate path has been set up, the end-nodes can be controlled (at step S6) to switch the Transport Plane traffic from the original connection to the alternate connection. The original connection can then be torn down (at step S8), without disrupting the Transport Plane traffic. In some embodiments, the alternate end-to-end path can be set up to traverse substantially the same path as the existing connection, and including (or omitting) the node to be added (or removed). In this case, the network reconfiguration is completed upon tear-down of the original connection at step S8. In other embodiments, it may be desirable to set up a new path that differs from the alternate path computed at step S2. In this case, the new path for the connection can be computed (or otherwise defined) at step S10, for example to traverse substantially the same path as the existing connection, and including a new node to be added to the connection path, or to bypass a node being removed from the connection path. A new connection can then be set up (at step S12) along the new path, and the end-nodes are controlled (at step S14) to switch the Transport Plane traffic from the alternate connection to the new connection. Finally, the alternate connection may be torn down (at S16) to release the network resources allocated to it.
Apart from the addition or deletion of individual nodes as described above, procedures for other types of network reconfigurations have not been yet been developed. As networks grow larger, however, it is expected that a time will come when such networks will need to be split into two or more domains. As network operating companies merge, partner or combine, merging of networks (or network domains) may become necessary. As standard-based connection-oriented Control Planes like GMPLS mature, a need may arise to migrate from pre-standard or proprietary Control Plane technology (such as OSRP) to the standardized Control Planes (eg: GMPLS). All of these operations comprise network reconfigurations and may need to be performed while not impacting existing Transport Plane connection traffic.
While the specific network reconfiguration procedures are expected to differ, in a standard-based connection-oriented Control Plane a typical network reconfiguration will invariably require changes in the Control Plane Name Space (CPNS). For example, when a new node is added to the network, or when the Control Plane 6 is extended to a network node that was previously not under control of the Control Plane 6, the CPNS must be updated to include at least the identifier and address of the new node in the Control Plane, so that the new node can participate in Control Plane signalling and functionality associated with any connections that traverse the new node. Similarly, when a Control Plane is split into two or more domains (or, conversely, when two or more domains are merged), the CPNS of the (or each) original domain must be updated to reflect the split (or merge).
The invention proposes a single and simple mechanism that can be incorporated into an in-service network reconfiguration procedure to take care of the changes to the Control Plane states for the connections, where such states are very much dependent on the Control Plane IDs, tags and/or addresses for the nodes/links/domains/areas/etc affected by the reconfiguration.
Techniques that enable in-service network reconfigurations involving changes in the Control Plane Name Space remain highly desirable.